The present invention relates generally to communication networks, and more specifically, to authorization, authentication, and accounting for virtual private networks.
The Internet has changed the way that companies do business. An outgrowth of Internet technology, Virtual Private Networks (VPNs) are transforming the daily method of doing business. Virtual Private Networks serve as private network overlays on public IP network infrastructures such as the Internet. A Virtual Private Network typically uses the Internet as the transport backbone to establish secure links with business partners, extend communications to regional and isolated offices, and significantly decrease the cost of communications for an increasingly mobile workforce. Access VPNs enable users to access corporate resources whenever, wherever, and however they require. Access VPNs encompass analog, dial, ISDN, digital subscriber line (DSL), mobile IP, and cable technologies to securely connect mobile users, telecommuters, or branch offices. There are various types of VPNs: MPLS (Multiprotocol Label Switching, see, RFC 2547 “BGP/MPLS VPNs”, E. Rosen et al., March 1999), IPSec (Internet Protocol Security), dial (L2TP, L2F, or PPTP), GRE tunnels, and ATM or Frame Relay PVCs.
A service that Service Providers (SPs) often offer to their VPN customers is managing the remote users access to the customers' VPNs. By managing the remote access, the SP relieves the customer from the responsibility of owning and managing network access servers (NAS) or home gateways for terminating a PPP session. In addition, the SP can benefit from the economies of scale by terminating the remote users of different customers on a shared device and mapping each to the corresponding customer's VPN. The shared device may be a network access server (NAS) or a home gateway, and may be referred to as a virtual home gateway (VHG).
The VHG is a SP device capable of terminating a PPP (Point-to-Point Protocol) sessions of different remote user and mapping each session to the corresponding customer's VPN. (For additional information on PPP see, RFC 1661, “The Point-to-Point Protocol (PPP)”, W. Simpson, July 1994)). Traditionally with PPP, the entity that terminates a PPP session is responsible for managing and coordinating all authorization, authentication, and accounting (AAA) operations related to that session.
An AAA server is a software application that performs authorization, authentication, and accounting functions, usually by interacting with network access servers, or gateways and databases or directories containing user information. AAA servers provide a security mechanism to protect a company's investments by permitting only certain entities (such as individuals or system processes) to access those investments, by governing what those entities can do once they are authenticated, and by logging or auditing the actions that are preformed for future reference and troubleshooting purposes. The SP's AAA server may be, for example, a RADIUS (Remote Authentication Dial In User Service) server or a TACACS (Terminal Access Controller Access Control System Plus) server. FIG. 1 illustrates a prior art system for providing authorization, authentication, and accounting operations at a service provider. The remote user 10 communicates with the SP VHG 12 via dial-up, DSL, or other type of connection. The SP has an AAA server 14 that includes a database 16 containing information on all remote users that have access to a VPN. After authenticating and authorizing the remote user 10, the SP connects the remote user with the VPN through its enterprise server (or firewall) 18. The VPN has its own private AAA server 20. As further described below, the SP's AAA server 14 may communicate directly with the VPN's private AAA server 20. The following describes details of the authorization, authentication, and accounting operations of this conventional system and drawbacks associated with this system.
Authorization is the process of giving permission to an entity to access a system resource. For example, network access can be restricted based on the identity of a client. Authorization provides the function of associating a remote user with a customer VPN and possibly applying policies specific to that particular VPN which may not be specific to the remote user. Authorization is usually based on either the user's domain name (e.g., @cisco.com) or, in the case of dial-up, the DNIS (Dial Number Information Service). The SP has two main options for performing the authorization functions. One is to configure the authorization information locally on the VHG. This is appropriate for SPs who do not have an AAA server. The second option is for the VHG to send an AAA request to the SP's AAA server to authorize the remote user.
Authentication is the process of verifying the identity of an entity. This process is usually done by exchanging information to prove one's identity. This information may take the form of a password, token, or one-time password, for example. In order for the SP to perform customer complete authentication of the customers' remote users, it must maintain a complete and up-to-date database of all the remote users of each customer. This has a clear drawback for large customers. One solution to this problem is to do proxy authentication. Proxy authentication requires the SP to have an AAA server. At session initiation time, the VHG is only capable of sending one AAA request per remote user. The same request must be used to both authorize and authenticate the remote user's PPP session.
The VHG first sends an AAA request to the SP AAA server for the incoming remote user. The SP's AAA server authorizes the remote user and associates it with a specific customer's VPN. The SP AAA server also determines the address of the VPN customer's AAA server. The SP AAA server proxies the AAA request to the customer's AAA server. The customer AAA server authenticates the remote user and responds to the SP AAA server with either success or failure. The SP AAA then sends a response back to the VHG with the results of the authorization and authentication operations. Drawbacks to this approach are that it requires the SP to have an AAA server and requires the SP AAA server and the customer AAA server to communicate. This can pose a security risk. Since the customer AAA server is in the customer VPN and the SP AAA server is either in the SP's management VPN or in its global routing table, routes must be redistributed (exported, imported, and filtered) between the customer VPN's routing table and the SP VPN's routing table so that the two AAA servers can communicate. It is possible to accomplish this route redistribution in a secure fashion, but it is a rather complex operation that is prone to configuration errors.
Accounting enables a network manager to keep track of the services and resources that are used by the users. The accounting process collects information such as the connection time, identity, and billing information. Conventional VHGs can only send accounting records to a single group of AAA servers that must be reachable via a global routing table. As a result, the VHG only sends accounting records to the SP's AAA server. However, because the VPN customers are also interested in receiving accounting records for their remote users, the SP's AAA server can be configured to save a copy of the accounting records and then proxy the same record to the VPN customer's AAA server. The process of proxying accounting records suffers from the same drawbacks discussed above for proxy authentication.
If the PPP session terminates on an access server or a home gateway inside the customer network, then the customer is typically responsible for the AAA operations. However, if the PPP session terminates on an SP's VHG, then the SP is responsible for the AAA operations. As described above, there are many drawbacks to the SP performing AAA operations and what is needed is a more secure and easier to configure mechanism for performing AAA operations in an SP managed remote access environment.